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Abstract 

The  Global  Information  Grid  (GIG)  is  the  military’s  computer  and  communications  network  which  supports  the  myriad 
of  military  missions.  Military  missions  are  highly  planned,  passing  through  many  hands  in  the  strategy-to-task  methodology 
to  ensure  completeness,  accuracy,  coordination,  cohesion,  and  appropriateness. A  benefit  of  this  planning  is  the  possibility 
to  collect  knowledge  of  future  conditions  that  could  be  of  use  to  network  designers  whose  goals  include  optimizing  and 
protecting  the  GIG. This  advanced  knowledge  includes  which  networked  military  equipment  will  be  involved,  what  their 
capabilities  are,  where  they  will  be,  when  they  will  be  there,  and  particulars  on  the  required  data  flows.  A  NetworkTasking 
Order  process  is  proposed  as  a  means  of  collecting  this  information,  analyzing  the  information  to  generate  network 
taskings,  and  disseminating  those  taskings.  Tactical  integration  of  assets  in  mobile  networks  is  introduced  as  another 
planning  variable  in  the  battlefield;  not  unlike  logistical  considerations  such  as  fuel,  ammunition,  water,  and  so  on  used 
currently  in  operation  planning.  Modeling  and  simulation  is  used  to  support  the  proposed  benefits. 
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I .  Introduction 

The  Global  Information  Grid  (GIG)  is  defined  in  Depart¬ 
ment  of  Defense  (DoD)  Directive  8100.1  as  the  ‘globally 
interconnected,  end-to-end  set  of  information  capabilities, 
associated  processes,  and  personnel  for  collecting,  pro¬ 
cessing,  storing,  disseminating  and  managing  information 
on  demand  to  warfighters,  policy  makers,  and  support  per¬ 
sonnel’.1  In  particular,  the  GIG  includes  all  equipment 
involved  in  the  transfer  of  information,  that  is,  the  military 
communications  network.  Many  subnetworks  of  the  GIG, 
especially  those  in  a  wartime  environment,  are  formed  by 
mobile  nodes. 

Mobile  nodes  are  by  necessity  wireless,  and  often  have 
little  infrastructure  with  which  to  connect  in  battlefield 
milieus.  Therefore,  nodes  must  have  the  capability  to  con¬ 
nect  directly  with  each  other  and  form  what  is  called  a 
Mobile  Ad-hoc  Network  (MANET).  Some  of  the  advantages 
of  MANETs  are  that  they  are  rapidly  deployable  and  can  be 
self-organizing.  Without  infrastructure,  each  node  must  act 
as  a  router  to  ensure  information  can  travel  between  nodes 


that  are  not  linked  directly.  Along  with  the  flexibility  that 
MANETs  provide,  there  are  also  some  disadvantages. 

Networks  involving  mobile  nodes  can  have  highly 
dynamic  topologies.  Without  careful  planning,  the  topolo¬ 
gies  that  form  can  suffer  from  poor  Quality  of  Service 
(QoS).  The  networks  could  have  bottlenecks,  or  worse,  be 
disconnected.  Certain  topologies  may  require  data  packets 
to  make  many  hops  to  travel  from  a  source  node  to  a  desti¬ 
nation  node,  which  leads  to  excessive  delays.  The  loss  or 
delay  of  information  can  have  dire  consequences.  At  the 
other  extreme,  a  topology  could  be  highly  redundant  and 
underutilized.  When  costs  such  as  battery  life,  maintenance, 
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or  frequency  allocation  are  considered,  this  is  decidedly 
wasteful.  It  is  in  the  DoD’s  best  interest  to  mitigate  these 
disadvantages  as  much  as  possible. 

In  a  MANET,  individual  nodes  often  make  their  own 
decisions  on  how  to  connect  to  the  network.  Unfortunately, 
what  may  appear  to  be  the  best  decision  for  a  singular  node 
may  not  be  in  the  best  interest  of  the  network  as  a  whole.  For 
instance,  one  particular  node  may  choose  to  send  informa¬ 
tion  through  a  path  that  has  the  fewest  hops  or  the  strongest 
signal,  but  as  a  result  increases  congestion  at  another  node. 
This  could  result  in  delays  or  dropped  packets  for  a  higher- 
priority  data  stream  trying  to  route  through  the  same 
congested  node.  A  congestion  control  approach  such  as 
Asynchronous  Transfer  Mode  (ATM)  virtual  circuits  would 
not  work  well  with  the  highly  mobile  military  networks,  and 
the  strategies  employed  by  Transmission  Control  Protocol 
(TCP)  make  it  difficult  to  guarantee  QoS.  What  is  needed  is 
a  means  to  prevent  congestion  rather  than  reacting  to  it. 

The  GIG  is  composed  of  many  parts.  Individuals  and 
mechanisms  charged  with  network  planning  need  to  be  aware 
of,  to  the  greatest  extent  possible,  what  composes  the  GIG, 
where  those  pieces  are,  what  their  capabilities  are,  and  how 
they  are  connected  or  communicating,  both  currently  and 
into  the  future.  Possession  of  this  ‘GIG-awareness’  would 
allow  for  tactical  integration  of  assets  as  another  planning 
variable  in  the  battlefield;  not  unlike  logistical  considerations 
such  as  fuel,  ammunition,  water,  and  so  on  as  used  currently 
in  operation  planning.  There  are  a  variety  of  ways  in  which 
such  awareness  can  be  leveraged  to  help  glean  improved  per¬ 
formance  out  of  the  equipment  being  used  and  to  aid  in 
protecting  that  equipment  from  cyber  attack. 

The  development  and  application  of  a  Network  Tasking 
Order  (NTO)  process  is  proposed  as  a  means  of  enhancing 
‘GIG-awareness’  by  taking  advantage  of  the  highly  planned 
nature  of  military  operations.  Military  missions  require 
careful  planning  to  ensure  appropriate  levels  of  force,  syn¬ 
chronization  of  effort,  minimization  of  risk,  and  the 
deconfliction  of  taskings,  airspace,  and  spectrum.  Unlike 
most  MANET  research  which  often  relies  on  random  mobil¬ 
ity  models,  in  military  scenarios  the  GIG  could  profit 
from  available  foreknowledge  of  the  general  locations  of 
assets,  when  they  will  be  there,  and  the  type  of  traffic  they 
will  generate.  The  NTO  would  be  an  analog  to  and  offspring 
of  the  Air  Tasking  Order  (ATO),  the  daily  tasking  of  air  mis¬ 
sions.  The  NTO  could  be  used  in  the  planning  stage  (as  a 
pre-NTO)  to  help  expose  shortcomings  or  redundancies  in 
the  network.  Also,  the  NTO  could  be  useful  in  the  execution 
stage  to  help  quickly  recover  from  unexpected  events  such 
as  finding  new  routes  for  traffic  when  a  node  fails. 

2.  Background 

The  idea  of  an  NTO  as  put  forth  in  this  paper  is  not  enti¬ 
rely  new.  Ranne  and  McKee4  advocate  that  United  States 


Strategic  Command’s  (USSTRATCOM)  Joint  Task  Force 
-  Global  Network  Operations  (JTF-GNO)  and/or  Air  Force 
Network  Operations  (AFNetOps)  should  conduct  concept 
and  prototype  development  with  GIG  NetOps  Tasking 
Orders  (GNTOs)  as  a  means  for  command  and  control  (C2) 
of  the  GIG.  These  GNTOs  could  be  used  ‘to  communicate 
not  only  what  to  do  and  who  does  it  with  what  assets;  but 
also  what  to  monitor  and  assess’.  The  authors  envision 
three  categories  of  GNTOs: 

1.  Standing  Orders:  for  routine  day-to-day  operations. 

2.  Cyclical  Orders:  to  communicate  planning  and 
resource  allocation  for  specific  periods  of  time, 
similar  to  an  ATO. 

3.  Dynamic  Orders:  to  communicate  near  real-time 
direction  for  security  and  allocation  issues. 

In  a  recent  email,  McKee5  indicated  that  USSTRATCOM 
leadership  liked  the  idea  and  are  very  interested  in  C2  of  the 
cyberspace  domain.  JTF-GNO  has  implemented  a  version 
of  the  GNTO  that  is  network  defense  focused,  but  not  really 
integrated  with  anything.  It  is  focused  on  computer/land 
networks  with  no  real  thoughts  on  air  networks  or  a  larger 
‘cyber’  perspective. 

The  concept  of  an  NTO  has  also  appeared  in  Stookey,6 
where  background  and  data  were  provided  regarding  the 
construction  of  a  notional  battlespace  for  testing  and  simu¬ 
lating  the  use  of  dynamic  networks  within  the  US  military. 
Stookey  elaborates  on  the  necessity  of  developing  an  NTO 
to  provide  dynamic  network  routers  a  basis  for  making 
predictive  decisions  about  where  given  nodes  are  spatially 
in  a  battlespace,  what  data  links  might  be  available,  the 
bandwidth  or  throughput  of  such  links,  the  bandwidth 
requirements  of  various  data  flows,  and  the  priority  of  the 
data  that  might  be  destined  to  or  coming  from  various 
nodes.  Pecarina7  envisions  an  NTO  in  which  a  Joint  Forces 
Cyber  Component  Commander  could  assign  weights  of 
effort  to  different  mission  goals  in  cyberspace.  In  addition, 
he  sees  the  NTO  as  a  means  of  addressing  a  QoS  issue.  That 
is,  the  NTO  will  help  to  move  to  a  point  where  information 
that  is  not  needed  or  wastes  time,  bandwidth,  and  energy  is 
blocked  to  allow  the  critical  data  to  get  through. 

There  are  already  military  documents  called  NTOs.  The 
624th  Operations  Center  (624  OC)  was  activated  in  August 
2009  along  with  a  new  numbered  air  force,  24  AF.  The  624 
OC  is  24  AF’s  C2  operations  center,  responsible  for  the  Air 
Force  provisioned  portion  of  the  GIG  for  the  purpose  of 
Network  Operations  (NetOps)  and  Network  Defense.8  In 
the  execution  of  that  role,  the  624  OC  commander  issues  a 
variety  of  order  types.  Currently,  these  order  types  include 
Maintenance  Tasking  Orders  (MTOs),  NetOps  Tasking 
Orders  (NTOs),  and  Time  Compliance  Network  Orders 
(TCNOs).  Briefly,  MTOs  are  for  generalized  cyber  mainte¬ 
nance  actions,  NTOs  are  for  urgent  defensive  actions,  and 
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TCNOs  are  for  routine  system  vulnerability  patching.9  These 
various  documents  are  more  directed  towards  actions  such 
as  moving  to  standard  desktop  configurations,  disallowing 
thumb  drive  use,  or  blocking  various  file  extensions  at  mail 
relays. 

Finally,  the  50th  Network  Operations  Group  (50  NOG) 
at  Shriever  Air  Force  Base  publishes  a  daily  NTO  to  assist 
in  C2  of  the  Air  Force  Satellite  Control  Network  which 
includes  such  as  the  Defense  Support  Program,  the  Navstar 
Global  Positioning  System,  the  Defense  Satellite  Commu¬ 
nications  System,  NATO  III,  and  Milstar.  This  schedule 
makes  sure  the  satellite  fliers  have  the  required  ground 
antenna  resources  to  perform  routine  tasks  and  to  perform 
telemetry  and  other  data  transfers.10  This  version  of  the 
NTO  appears  most  similar  to  the  product  of  the  NTO  pro¬ 
cess  proposed  herein,  but  focuses  on  a  much  smaller  portion 
of  the  GIG. 

With  several  organizations  currently  using  documents 
called  ‘NTO’,  it  may  be  advisable  to  attach  a  type  designa¬ 
tion  to  the  name  to  avoid  confusion.  For  example,  in  the 
future,  the  name  NTO-A  could  be  used  to  emphasize  the 
relationship  it  has  with  the  ATO  and  to  distance  itself  from 
the  NTOs  produced  by  the  624  OC  and  the  50  NOG. 

3. The  NTO  Process 

The  NTO  is  envisioned  as  an  analog  to  and  offspring  of  the 
ATO,  the  daily  tasking  of  air  missions.  ATOs  are  created  by 
the  Combat  Plans  Division  (CPD)  of  the  Joint  Air  and  Space 
Operations  Center  (JAOC).  In  the  future,  the  NTO  may  be 
more  of  a  sibling  to  the  ATO,  providing  a  daily  tasking  of 
network  missions  to  support  the  air  missions.  In  the  (maybe 
not  so)  distant  future,  the  roles  may  reverse  with  the  ATO 
created  as  a  support  for  the  NTO.  In  the  meantime,  the 
NTO  creation  process  should  follow  a  cycle  similar  to  the 
ATO  cycle.  Therefore,  it  is  pertinent  to  detail  the  ATO’s  life 
cycle  and  indicate  how  the  NTO  would  fit  in. 

The  JAOC’s  Strategy  Division  develops  an  Air  Opera¬ 
tions  Directive  (AOD)  which  provides  high-level  details  on 
what  effects  are  to  undertaken  and  the  level  of  effort  by 
force  elements.  Based  on  the  guidance  in  the  AOD,  targets 
are  aligned  with  objectives  by  the  Targeting  Effects  Team 
in  the  CPD  to  produce  the  Joint  Integrated  Prioritized 
Target  List  (JIPTL).  The  J1PTL  is  sent  to  the  Targets  and 
Combat  Assessment  Team  in  the  Intelligence,  Surveillance, 
and  Reconnaissance  (ISR)  Division  to  determine  the  quan¬ 
tity  of  weapons  required  for  each  apportioned  target.  After 
weaponeering,  the  JIPTL  goes  to  the  Master  Air  Attack 
Plan  (MAAP)  Team  in  the  CPD.  During  the  MAAP  pro¬ 
cess,  weapon  systems  resources  are  matched  to  each  target. 
Overall  the  CPD  is  responsible  for  developing  the  MAAP, 
special  instructions  (SPINS),  and  the  ATO.  The  MAAP  is 
combined  with  the  SPINS  and  other  inputs  such  as  ISR  col¬ 
lection  requirements  to  produce  the  ATO.  When  the  ATO  is 


complete,  it  is  compiled  into  the  Theater  Battle  Management 
Core  System  (TBMCS)  and  distributed  electronically  to  all 
users.  Normally,  the  CPD  works  the  two  ATO  periods 
beyond  the  current  ATO,  putting  the  ATO  into  a  3-day  cycle 
of  planning,  production,  and  execution." 

In  addition  to  the  documents  described  above,  three  other 
important  documents  come  from  the  C2  Planning  Team  of  the 
CPD:  the  daily  Airspace  Control  Order  (ACO),  the  Tactical 
Operations  Data  (TACOPDAT),  and  the  daily  Operation 
Tasking  Data  Link  (OPTASK  LINK).  The  ACO  is  used  to 
define  and  establish  special  purpose  airspace  (air  corridors, 
air  defense  areas,  reference  points,  etc.)  for  management  and 
control.  The  TACOPDAT  is  used  to  establish  air  defense  and 
antiair  warfare  responsibilities.  The  TACOPDAT  establishes 
locations  and  frequencies  of  ground  C2  agencies,  combat 
air  patrol  stations,  airborne  early  warning  and  radio  relay 
stations,  air-to-air  refueling  stations,  and  aircraft  handover 
points.  The  OPTASK  LINK  specifies  data  link  procedures 
within  a  battle  group  and  serves  as  a  list  of  who  can/may  talk 
to  whom.  It  contains  information  such  as  unit  locations, 
frequencies,  duties,  and  filter  plans. 

The  goal  of  the  NTO  process  at  this  point  is  not  to  create 
network  missions  to  create  effects,  but  rather  to  support  the 
air  missions  in  the  ATO  in  achieving  their  designated  effects. 
The  NTO  process  is  envisioned  as  a  means  of  optimizing 
the  network:  the  network  composed  of  the  various  military 
equipment  enacting  the  ATO.  This  means  the  NTO  process 
should  closely  follow,  or  be  done  in  unison  with,  the  ATO 
process.  The  team  performing  the  NTO  process  needs  to  be 
placed  in  the  JAOC  (ideally  in  the  CPD)  to  have  direct 
access  to  the  data  they  require  and  to  interact  immediately 
with  the  various  divisions  and  teams  of  the  JAOC.  The 
teams  in  the  JAOC  also  need  the  interaction  from  the  NTO 
Team,  because  the  process  of  creating  the  NTO  can  add 
insight  that  might  result  in  changes  or  additions  to  the  ATO. 

The  process  of  creating  an  NTO  should  not  be  delegated 
to  the  ATO  production  team,  or  simply  result  in  the  addition 
of  new  fields  to  the  ATO  document.  The  personnel  on  the 
various  teams  in  the  JAOC  are  highly  specialized.  The 
members  of  the  ATO  production  team  typically  have  opera¬ 
tional  experience  in  the  various  weapons  systems  that  are 
being  tasked  and  are  not  trained  in  network  planning.  A 
dedicated  team  of  networking  experts,  likely  from  the  com¬ 
munications  and  information  career  field  (33S),  would  be 
best  suited  to  the  job.  As  the  DoD  moves  more  towards 
network-centric  warfare  and  operations,  having  an  NTO 
separate  from  the  ATO  would  allow  for  the  evolution  of  the 
NTO  as  an  entity  without  constant  turmoil  to  the  already 
established  ATO. 

A  large  portion  of  the  data  needed  for  the  NTO  will  come 
from  the  ATO  itself  (and  its  MAAP  predecessor).  There  are 
many  other  planning  documents  such  as  the  Space  Tasking 
Order  (STO),  TACOPDAT,  OPTASK  LINK,  and  the  Joint 
Communications  Electronics  Operating  Instruction  (JCEOI) 
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that  contain  useful  information  as  well.  The  STO  is  another 
document  that  is  developed  in  parallel  with  the  ATO,  like  the 
NTO  would  be.  Its  primary  purpose  is  for  tasking  space 
assets  with  specific  missions.  Since  satellites  are  used  for 
communication,  this  information  is  of  interest  to  network 
designers.  The  TACOPDAT  and  OPTASK  LINK  were  des¬ 
cribed  above.  The  JCEOI  is  used  for  frequency  allocation 
and  deconfliction. 

The  content  and  structure  of  the  ATO,  STO,  TACOPDAT, 
and  OPTASK  LINK  are  given  in  great  detail  by  the  MITRE 
Corporation  Technical  Staff.12  These  documents  are  all  writ¬ 
ten  in  United  States  Message  Text  Format  (USMTF).  USMTF 
produces  human/machine-readable  documents  in  a  uniform 
style  with  a  large  amount  of  vocabulary  control.  This  same 
format  should  be  used  for  the  NTO.  Over  370  different  types 
of  messages  use  USMTF,12  which  is  a  familiar  format  to  most 
service  members.  Existing  message  generators  and  browsers 
could  easily  be  adapted  to  accommodate  NTOs. 

To  get  an  idea  of  the  level  of  detail  available  to  network 
planners,  the  structure  of  an  ATO  is  now  broken  down  with 
a  high-level  overview  of  content.  All  of  the  missions  in  the 
ATO  are  grouped  first  by  tasked  country,  then  by  tasked 
service,  and  after  that  by  individual  tasked  units.  It  makes 
sense  to  keep  this  structure  in  an  NTO  so  that  the  units  that 
own  each  network  component  can  easily  find  the  pieces 
they  are  responsible  for  and  configure  them  for  the  planned 
day.  In  addition,  it  is  possible  that  communications  will 
exist  between  the  asset  and  its  home  unit  that  need  to  be 
planned  for. 

Once  the  ATO  gets  down  to  the  individual  unit  level,  all 
missions  that  a  particular  unit  is  responsible  for  appear 
sequentially.  Within  each  mission,  the  number  and  type  of 
aircraft  along  with  call  sign  and  primary  configuration  are 
given.  The  following  information  may  also  be  listed:  sec¬ 
ondary  configuration  codes,  Link  16  abbreviated  call  sign, 
Tactical  Air  Navigation  system  (TACAN)  channel,  primary 
Joint  Tactical  Information  Distribution  System  Unit  add¬ 
ress,  and  identification  friend  or  foe/selective  identification 
feature  (IFF/SIF)  mode  and  code. 

Each  mission  has  a  preferred  mission  type  or  designa¬ 
tion.  Mission  type  does  not  necessarily  need  to  go  into  the 
pre-NTO,  but  it  may  give  a  clue  as  to  the  types  of  traffic  to 
expect.  For  example,  a  combat  search  and  rescue  (CSAR) 
mission  will  have  different  traffic  characteristics  than  air 
reconnaissance  or  aerial  refueling.  The  expected  quantity 
and  burstiness  of  traffic  flows  are  important  measures  to 
include  in  the  pre-NTO.  These  characteristics  can  be  known 
through  historical  precedence.  The  concept  of  historical 
precedence  is  addressed  more  fully  in  the  following. 

Missions  in  the  ATO  usually  include  a  route  with  alti¬ 
tudes  and  speeds.  Routes  can  either  be  a  round  trip  to  a  target 
location  with  departure/retum  locations  and  times,  one-way 
travel  with  departure/arrival  locations  and  times,  or  orbit 
information  with  departure/return  locations  and  times.  In 


any  case,  given  this  information,  there  is  some  general  idea 
of  where  an  aircraft  is  going  to  be  and  when  it  will  be  there. 
When  satellites  fly  over  for  limited  but  predictable  time 
spans,  the  utilization  of  these  resources  can  be  planned  for 
ahead  of  time.  For  example,  a  directional  antenna  can  be 
prepositioned  to  the  expected  pointing  angle  so  that  it  is 
ready  for  service  when  needed.  Thus,  some  simplified  ver¬ 
sion  of  this  information  should  be  included  in  the  pre-NTO. 

Missions  in  the  ATO  are  also  given  priorities,  and  one 
can  generally  assume  the  transmissions  of  a  mission  would 
have  corresponding  priority.  Thus,  it  will  be  imperative  to 
carry  these  priorities  into  the  pre-NTO  to  allow  for  ranking 
of  traffic  flows.  By  including  the  priority  of  certain  traffic 
flows,  routing  agents  can  use  this  information  to  make  deci¬ 
sions  in  situations  of  congestion.  The  agents  can  decide  to 
allow  the  high  priority  information  to  pass  through  while 
dropping  or  delaying  the  lower  priority  information.  Other 
alternatives  are  directing  information  over  different  routes, 
storing  information  to  send  at  times  of  lower  activity,  or 
requesting  nodes  to  slow  down  or  stop  transmissions. 

As  can  be  seen,  there  is  a  great  deal  of  information  con¬ 
tained  in  the  ATO  that  can  be  used  for  network  planning 
purposes.  The  other  planning  documents  such  as  the  STO, 
TACOPDAT,  and  OPTASK  LINK  likewise  hold  important 
details.  Analysts  in  the  JAOC  can  know  in  advance  which 
nodes  will  be  involved  in  the  network  and  where  they  will 
be.  This  is  clearly  an  advantage  over  the  use  of  random 
mobility  models.  Since  the  assets  forming  the  nodes  are  not 
homogeneous,  it  is  important  that  network  planners  know 
what  capabilities  those  assets  have. 

There  may  be  differences  in  networking  capabilities 
between  two  assets  of  the  same  type.  For  example,  the 
capabilities  of  an  A- 10  from  one  unit  could  be  radically  dif¬ 
ferent  from  those  of  an  A- 10  from  another  unit.  However, 
within  a  single  unit  the  differences  should  be  minimal.  It 
would  be  beneficial  to  have  available  a  baseline  capability 
for  each  asset  type  by  unit.  Some  characteristics  that  would 
be  valuable  include: 

•  types  of  interfaces  (free  space  optical,  radio  fre¬ 
quency,  etc.); 

•  number  of  interfaces; 

•  functional  areas  implemented  for  each  data  link; 

•  frequencies  or  channels  available; 

•  transmission  speed/range; 

•  data  forwarding  capabilities; 

•  encryption  capability; 

•  accepted  protocols; 

•  set-up  time;  and 

•  queue  characteristics. 

This  capability  information  should  be  placed  into  a  central¬ 
ized  database  at  the  JAOC  so  that  when  an  asset  is  tasked,  the 
networking  capabilities  of  that  asset  can  be  automatically 
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available  to  the  network  planners.  There  does  not  appear  to 
be  an  all-inclusive  database  containing  this  infonnation  cur¬ 
rently  in  existence.  Although  it  would  likely  be  classified,  it 
ought  to  be  fairly  straightforward  to  compile  such  a  database. 
Once  constructed,  the  database  could  be  kept  current  through 
updates  from  depots,  program  offices,  or  individual  units.  A 
good  basis  for  building  this  capabilities  database  would  draw 
from  the  Joint  Spectrum  Center  (JSC)  Equipment,  Tactical, 
and  Space  (JETS)  database,  which  is  already  accessible  to 
personnel  in  the  JAOC.  The  JETS  database  contains  detailed 
technical  information  about  communications,  radar,  and 
electronic  warfare  equipment  as  well  as  operational  parame¬ 
ters  for  each  subsystem  and  component.13 

The  military  usually  does  an  outstanding  job  of  perform¬ 
ing  after-action  reviews  and  cataloging  best  practices  and 
areas  where  improvements  are  needed.  The  historical  quali¬ 
ties  of  various  mission  types  are  certainly  tabulated  in 
various  locations  as  lessons  learned,  listed  as  general  guide¬ 
lines,  or  stored  in  the  collective  memory  of  seasoned 
sergeants.  As  mentioned  above,  aspects  such  as  the  expected 
quantity  and  burstiness  of  traffic  flows  for  various  mission 
types  are  important  measures  to  be  placed  into  the  pre- 
NTO.  To  ensure  continuity  as  personnel  change  and  to 
increase  consistency  from  NTO  to  NTO,  this  historical  pre¬ 
cedence  should  be  written  down.  As  time  goes  by,  the 
measurements  will  become  more  refined.  After  each  ATO/ 
NTO  is  executed,  new  measurements  can  be  added  to  the 
old  to  extend  the  usefulness.  This  would  also  reflect  shifts 
as  conditions  change  over  time  and  from  conflict  to  con¬ 
flict.  Types  of  metrics  that  should  be  recorded  for  each 
mission  type  include: 

•  expected  communications  partners; 

•  type  of  data  transmitted; 

•  bandwidth  required  (average,  burst); 

•  quality  of  service  requirements;  and 

•  encryption  needs. 

Not  only  would  such  documentation  help  assure  that  assets 
receive  enough  bandwidth  for  their  needs,  but  it  could  also 
help  identify  where  bandwidth  is  over-allocated.  This  is 
especially  important  as  the  finite  spectrum  available  gets 
more  and  more  utilized  and  deconfliction  becomes  more 
difficult.  In  addition,  from  the  network  planners’  frame  of 
reference,  it  would  provide  a  rough  idea  of  the  amount  and 
type  of  traffic  that  needs  to  be  routed  in  the  network. 

The  assets  tasked  in  the  planning  documents  can  be 
cross-referenced  with  the  capabilities  database.  Historical 
precedence  for  the  various  mission  types  can  be  pooled.  The 
combined  infonnation  can  then  be  collated  into  a  daily 
schedule  for  the  network.  This  is  a  pre-NTO.  No  network 
specific  taskings  have  been  made  yet.  Analysis  can  now  be 
performed  upon  this  pre-NTO.  By  having  a  plan  in  place,  it 
becomes  more  evident  where  there  could  be  single  points  of 


failure,  gaps  in  connectivity,  or  bottlenecks.  In  such  cases,  it 
might  be  possible  to  change  an  orbit  or  add  an  extra  asset. 
For  instance,  one  waypoint  of  an  E-3 ’s  orbit  could  be  moved 
slightly  to  allow  periodic  high-bandwidth  Line-of-Sight 
(LOS)  communications  to  a  ground  unit  that  would  other¬ 
wise  be  plagued  with  constant  low-bandwidth  connections. 
Another  example  could  be  the  addition  of  a  communica¬ 
tions  relay  mission  for  an  Unmanned  Aerial  System  (UAS) 
to  linger  over  a  certain  location  to  act  as  a  wireless  router  in 
support  of  a  high-priority  mission. 

In  addition  to  eliminating  deficiencies,  analysis  could 
also  be  used  to  optimize  communications  or  to  boost  secu¬ 
rity.  For  example,  topology  control  algorithms  could  be 
employed  to  assign  routes  that  maximize  throughput  while 
minimizing  the  number  of  links  utilized.  Another  example 
might  be  adding  variations  to  prevent  day-to-day  communi¬ 
cations  patterns  from  becoming  predictable.  The  variations 
could  be  as  simple  as  rotating  frequencies,  or  more  involved 
like  implementing  polymorphism. 

Feedback  from  the  analysis  can  thus  be  used  to  make 
necessary  changes  to  the  ATO  and  other  planning  docu¬ 
ments  before  they  are  published.  Once  sufficient  analysis 
and  feedback  cycles  have  been  perfonned,  appropriate  net¬ 
working  directives  can  be  formed  and  published  through 
TBMCS  in  a  finished  NTO  for  units  to  download.  This 
NTO  process  is  illustrated  in  Figure  1. 

4.  Example  NTO  Process 

It  may  be  useful  at  this  point  to  illustrate  how  a  translation 
of  a  single  mission  from  an  ATO  into  an  NTO  might  look. 
The  example  provided  is  academic  and  does  not  represent 
any  real  mission.  In  the  ATO,  each  line  of  data,  or  set,  is 
terminated  by  7/’;  however,  due  to  length  it  may  wrap  to 
fill  multiple  lines  of  text.  Within  a  set,  fields  are  separated 
by  7’.  Fields  containing  are  optional  and  no  data  has 
been  entered.  Figure  2  shows  a  few  sets  from  an  example 
ATO  that  pertain  to  a  single  mission. 

The  first  three  sets  detail  whom  is  being  tasked  in  in¬ 
creasing  specificity.  The  first  set  indicates  that  the  tasked 
country  (TSKCNTRY)  is  the  US.  The  second  set  designates 
the  Air  Force  (F)  as  the  service  being  tasked  (SVCTASK). 
The  third  set  specifies  the  unit  being  tasked  (TASKUNIT) 
and  its  location.  Here,  it  refers  to  the  23rd  Fighter  Squadron 
(23FS)  at  Spangdahlem  Air  Base  in  Germany.  The  location 
in  this  instance  is  given  by  the  International  Civil  Aviation 
Organization  (ICAO)  four-character  identifier  ETAD. 
Location  can  also  be  specified  by  place  name  or  by  latitude/ 
longitude. 

The  fourth  set  contains  aircraft  mission  data  (AMSNDAT) 
with  1 2  fields  of  information.  The  first  field  is  the  residual 
mission  indicator.  An  ‘N’  means  that  the  mission  is  non¬ 
residual;  the  mission  falls  entirely  within  the  ATO  period. 
The  next  field  is  for  the  mission  number  identification, 
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Figure  I .  NTO  data  flow 


TSKCNTRY/US// 

SVCTASK/F// 

TASKUNIT/23FS/ICAO:ETAD// 

AMSNDAT/N/D123HB/-/-/-/SEAD/-/-/DEPLOC:KGZ6/241200 

ZAPR/ARRLOC: 

KDZ7/241 300ZAPR// 

MSNACFT/1/ACTYP:F16CJ/SUPP01/2HARM/-/20001/301 11// 
AMSNLOC/-/-/-/21 0/1// 


Figure  2.  Sample  ATO  mission 

here  it  is  D123HB.  The  third,  fourth,  and  fifth  fields  have 
been  left  blank.  Field  six  holds  the  preferred  type  or  desig¬ 
nation  for  the  mission.  In  this  case,  it  is  a  Suppression 
Enemy  Air  Defense  (SEAD)  mission.  Fields  seven  and 
eight  have  been  left  blank.  Field  nine  is  used  to  specify  the 
departure  location  of  the  mission  if  it  differs  from  the  loca¬ 
tion  specified  in  the  TASKUNIT  set.  An  ICAO  identifier, 
KGZ6,  is  given  for  the  location.  Field  10  gives  the  day, 
time  and  month  of  departure,  April  24  at  1200  Zulu.  Field 
1 1  provides  the  recovery  location  of  the  mission  if  other 
than  the  location  specified  in  the  TASKUNIT  set.  Again, 
an  ICAO  identifier,  KDZ7,  is  given  for  the  location. 
Finally,  field  12  gives  the  day,  time  and  month  of  recovery, 
April  24  at  1300  Zulu. 

The  fifth  set  holds  individual  aircraft  mission  data 
(MSNACFT)  with  seven  fields  of  information.  The  first 


field  gives  the  number  of  aircraft  as  1.  The  second  field 
provides  the  type  and  model  of  aircraft  as  an  F-16CJ 
Fighting  Falcon.  The  aircraft  call  sign,  SUPP01,  is  placed 
in  field  three.  In  the  primary  configuration  code  field, 
2HARM  indicates  the  aircraft  should  be  equipped  with  two 
AGM-88  high-speed  anti-radiation  missiles.  Field  five  has 
been  left  blank.  Fields  six  and  seven  are  both  for  IFF/SIF 
codes.  In  field  six,  20001  indicates  a  mode  2  code  (personal 
unit  identity)  with  octal  value  0001.  In  field  seven,  30111 
indicates  a  mode  3  code  (normal  air  traffic  control  identity) 
with  octal  value  0111. 

Finally,  in  the  sixth  set,  additional  mission  location 
(AMSNLOC)  information  is  given  with  five  fields.  This  set 
provides  mission  location  information  for  missions  which 
have  no  specific  target  location,  for  example  orbits  or  alerts. 
Fields  one,  two,  and  three  are  left  blank.  Field  four  provides 
the  vertical  distance  in  hundreds  of  feet  above  mean  sea 
level.  A  value  of  210  indicates  the  mission  should  fly  at 
21,000  feet.  The  last  field  is  the  code  for  the  priority 
assigned  to  a  mission,  which  in  this  example  is  1 . 

Note  that  in  a  few  short  lines,  there  is  some  pretty 
detailed  information  about  where  this  particular  F-16CJ 
will  be  and  when  it  will  be  there.  Given  the  departure  and 
recovery  locations  of  the  mission,  intermediate  locations 
can  be  interpolated.  Similar  information  will  be  given 
for  all  other  aircraft  flying  during  the  same  time  period. 
Presumptions  can  also  be  made  regarding  with  whom  this 
aircraft  will  be  communicating. 
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Suppose  that  a  capabilities  database  contains  the  follo¬ 
wing  (hypothetical)  information  regarding  F-16CJs  from 
the  23rd  Fighter  Squadron: 

•  Equipped  with  one  Improved  Data  Modem  (IDM- 
302)  capable  of  16  kbps  digital  communications 
over  four  independent  channels  accepting  AFAPD, 
TACFIRE,  IDL,  and  MTS  protocols.14 

•  The  1DM-302  is  interfaced  with  an  AN/ARC- 164 
Ultra  High  Frequency  (UHF)  Airborne  Radio  which 
receives  AM  signals  at  levels  between  -101  dBm 
and  +2  dBm  and  features  1-10  W  AM,  100  W  FM, 
25  kHz  channel  spacing  over  a  frequency  range  of 
225.000-399.975  MHz,  and  LOS  voice.15 

•  The  aircraft  includes  an  omni-directional  UH-408 
UHF  Blade  Antenna  with  -1  dB  gain  over  225-400 
MHz  and  50  Q  impedance.16 

Finally,  based  on  historical  records  of  SEAD  missions,  an 
average  or  expected  data  rate  along  with  a  peak  data  rate  can 
be  established.  For  the  sake  of  the  example,  suppose  that  the 
average  traffic  rate  is  5  kbps  with  bursts  up  to  15  kbps.  It  is 
also  possible  to  predict  with  whom  the  F-16CJ  will  be  com¬ 
municating.  There  will  likely  be  communications  between 
various  aircraft  in  the  same  strike  package.  These  other  air¬ 
craft  are  identified  in  the  ATO.  Also,  there  should  be 
communications  with  an  E-3  Sentry  Airborne  Warning  and 
Control  System  (AWACS)  providing  situational  awareness 
of  the  battlefield  and  battle  management.  The  AWACS  clos¬ 
est  to  the  F-16CJ  during  this  mission  can  be  identified  from 
the  ATO.  There  may  also  be  communications  between  the 
F-16CJ  and  its  home  base  and  with  the  JAOC. 

All  of  this  information  is  of  interest  to  analysts  who  are 
trying  to  optimize  the  network  and  eliminate  potential  gaps 
in  connectivity  or  bottlenecks.  This  information  is  collated 
into  a  pre-NTO.  The  data  in  the  pre-NTO  can  then  be  fed 
into  tools  such  as  the  topology  control  algorithms  or  other 
programs  that  may  exist  or  have  yet  to  be  created.  The  pre- 
NTO  may  have  the  appearance  of  Figure  3. 


TSKCNTRY/US// 

SVCTASK/F// 

TASKUNIT/23FS/ICAO:ETAD// 

AMSNDAT/N/D123HB/-/-/-/SEAD/-/-/DEPLOC: 

KGZ6/241200ZAPR/ARRLOC: 

KDZ7/241 300ZAPR// 

MSNACFT/1/ACTYP:F16CJ/SUPP01/2HARM/-/20001/301 1 1// 
AMSNLOC/-/-/-/21 0/1// 

MODEMDAT/1/TYPE:IDM302// 

RADIODAT/1/TYPE:ARC164// 

IFACEDAT/1/TYPE:UH408// 

EXPCOMM/AVE:5/BURST:15/1// 

COMMLINK/ICAO:ETAD/ICAO:JAOC/CALL:SKYWATCH43// 


Note  that  the  first  six  sets  in  Figure  3  are  repeated  from 
the  ATO.  This  is  important  information,  most  of  which  could 
be  of  use  to  analysts.  Five  new  sets  have  been  added  using 
the  same  USMTF  fonnat.  The  first  added  set,  MODEMDAT, 
provides  information  on  the  modem(s)  carried  by  the  asset. 
The  first  field  in  this  set  gives  the  number  and  the  second 
field  gives  the  type.  Here  it  lists  1  IDM-302  modem.  These 
fields  can  be  repeated  if  there  are  multiple  types  of  modems. 
The  second  and  third  added  sets  have  a  very  similar  fonnat. 
The  RADIODAT  set  gives  the  number  and  type  of  radio(s) 
on  the  asset.  The  IFACEDAT  set  lists  the  number  and  type  of 
interfaces  (or  antennas)  being  used.  It  may  be  necessary  to 
make  these  sets  hierarchical  if,  for  instance,  different  mod¬ 
ems  are  paired  with  different  radios  and  antennas.  These 
three  sets  are  derived  from  the  infonnation  in  the  capabilities 
database. 

The  last  two  added  sets  are  derived  from  historical 
precedence.  The  EXPCOMM  set  lists  information  on  the 
expected  communications  traffic  from  this  asset  on  this 
particular  mission.  The  first  field  gives  the  anticipated  aver¬ 
age  traffic  rate  in  kilobytes  per  second.  The  second  field 
gives  the  anticipated  maximum  traffic  rate  in  kilobytes  per 
second.  The  final  field  indicates  the  priority  of  the  commu¬ 
nications.  In  this  case,  the  priority  is  identical  to  the  mission 
priority  listed  in  the  AMSNLOC  set.  This  set  would  also  be 
a  good  place  to  put  fields  such  as  encryption  requirements, 
type  of  traffic  (voice,  video,  telemetry,  etc.)  being  sent,  pro¬ 
tocols  being  used,  and  so  on.  The  COMML1NK  set  lists 
some  of  the  main  communications  partners  for  the  asset. 
The  field  in  this  set  is  repeated  for  each  expected  traffic 
recipient.  The  labels  in  the  field,  ICAO  and  CALL,  indi¬ 
cate  how  the  recipient  is  identified.  The  first  two  fields  in 
this  example  give  the  ICAO  identifiers  for  the  F-16CJ’s 
home  station  and  for  the  JAOC.  The  last  field  gives  the 
aircraft  call  sign  of  an  AWACS  that  will  be  coordinating 
the  mission. 

Finally,  an  example  can  now  be  shown  of  a  tasking  that 
could  be  generated  and  given  to  this  particular  mission. 
Suppose  that  it  has  been  determined  that  during  this  mis¬ 
sion,  the  F-16CJ  should  route  all  traffic  destined  for  the 
JAOC  through  a  KC-135  tanker  with  call  sign  FUEL03  in 
an  orbit  named  BLUE  23  in  the  vicinity  of  the  mission.  This 
tasking  may  have  the  appearance  of  the  code  in  Figure  4. 


TSKCNTRY/US// 

SVCTASK/F// 

TASKUNIT/23FS/ICAO:ETAD// 

TASKNODE/ACTYP:F16CJ/SUPP01// 

1 RTEDAT 

/DEST  /START  /STOP  /NHOP  /LOC 

/ICAO:JAOC  /241200ZAPR  /241300ZAPR  /CALLFUEL03 
/BLUE  23// 


Figure  3.  Sample  pre-NTO  mission 


Figure  4.  Sample  NTO  tasking 
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Note  that  the  first  three  sets  in  Figure  4  are  repeated 
from  the  ATO  and  the  pre-NTO.  These  sets  narrow  down 
what  is  being  given  the  tasking.  The  fourth  set,  TASKNODE, 
specifies  which  node  in  the  network  is  being  tasked.  Here  it 
is  the  F-16CJ  with  call  sign  SUPP01.  The  last  three  lines 
form  what  is  known  as  a  columnar  set.  Columnar  sets  are 
arranged  in  vertical  columns  under  an  appropriate  column 
heading.  The  first  line  has  the  set  name,  which  for  columnar 
sets  must  begin  with  a  number.  Flere  the  set  is  named 
1RTEDAT,  indicating  that  the  set  is  used  for  specifying 
data  routes.  The  second  line  has  the  column  headers  which 
designate  the  type  of  information  located  in  each  column. 
The  third  line  contains  the  information  for  this  set.  The 
information  in  this  line  is  entered  so  that  it  falls  under  the 
proper  column  headers.  The  first  column,  DEST,  indicates 
the  final  destination  for  the  traffic  that  is  being  routed.  The 
final  destination  here  is  referenced  by  the  ICAO  code  for 
the  JAOC.  The  next  two  columns,  START  and  STOP,  spec¬ 
ify  the  day,  time  and  month  span  over  which  this  route  is  to 
be  used.  Here,  the  time  span  corresponds  to  the  full  mission 
duration  found  in  the  ATO,  from  1200  to  1300  Zulu  on  24 
April.  The  fourth  column,  NHOP,  indicates  the  next  hop  for 
traffic.  The  KC-135  is  referenced  using  its  call  sign.  The 
final  column,  LOC,  indicates  the  location  of  the  next  hop. 
Here,  BLUE  23  refers  to  the  KC-135’s  orbit.  Additional 
columns  could  be  added  as  needed.  For  example,  channel, 
encryption  type,  interface,  etc.  could  be  included  in  this  set. 
As  many  information  lines  as  needed  can  be  used  with 
columnar  sets.  This  set  resembles  a  routing  table. 

5.  Simulation 

A  simple,  illustrative  scenario  is  now  provided  to  give  an 
example  of  how  a  priori  knowledge  of  network  conditions 
identified  during  the  planning  stage  of  the  NTO  process 
could  translate  into  increased  QoS  during  the  execution 
stage.  The  same  scenario  is  examined  from  two  points  of 
view  (POVs).  First,  the  scenario  is  considered  with  a  local¬ 
ized  POV,  where  no  NTO  process  is  available  to  guide 
decisions  made  at  the  various  nodes.  Second,  a  more  global 
POV  is  considered,  where  an  NTO  process  has  identified  a 
problem  and  directives  are  issued  to  address  it.  Modeling 
and  simulation  are  utilized  to  quantify  the  impact  of  imple¬ 
menting  an  NTO  process. 

5.  / .  Scenario 

The  scenario  consists  of  two  individual  sources  generating 
information  that  needs  to  be  sent  to  a  common  headquarters 
(HQ).  HQ  is  far  enough  away  that  direct  communication 
from  the  two  sources  is  not  available,  but  there  is  an  inter¬ 
mediate  node  that  can  act  as  a  router.  Both  sources  have  a 
36-kbps  connection  to  the  router,  and  the  router  has  a 
36-kbps  connection  to  HQ.  Source  1  (Sl),anMQ-l  Predator, 


will  produce  a  high-priority  video  feed  at  a  rate  of  30.6  kbps 
over  a  30-minute  time  span  that  falls  between  the  hours  of 
1400  and  1500.  Source  2  (S2),  a  sensor  net,  produces  a  con¬ 
tinuous  stream  of  data  at  a  rate  of  7.2  kbps.  S2’s  data  is  of 
lower  priority,  as  it  is  collated  at  HQ  and  reviewed  once 
daily.  In  addition  to  the  router,  there  will  also  be  an  E-3 
Sentry  (AWACS)  aircraft  flying  a  30-minute  orbit  during  the 
hours  from  1300  to  1800  in  the  airspace  between  S2  and 
HQ.  This  particular  AWACS  is  known  to  be  carrying  equip¬ 
ment  that  allows  wireless  LOS  networking  at  a  capacity  of 
28.8  kbps.  The  orbit  is  such  that  it  will  not  be  in  LOS  of  SI. 
It  will  be  within  LOS  of  both  the  S2  and  HQ  for  10  minutes 
each,  with  no  overlap  in  these  time  spans.  Thus,  the  aircraft 
cannot  act  as  a  router.  However,  the  aircraft  can  be  used  as  a 
data  ferry,  storing  the  infonnation  that  is  uploaded  from  S2 
and  downloading  it  later  to  HQ  when  it  is  in  range.  See 
Figure  5  for  an  overhead  view  of  the  scenario. 

This  scenario  is  first  considered  without  an  NTO  process 
in  place  for  guidance.  Si’s  operators  do  not  have  any 
options  for  routing  the  video  feed;  they  must  utilize  the 
router.  S2’s  operators  have  a  little  more  flexibility.  Given 
the  choice  between  sending  its  traffic  to  the  router  or  to  the 
AWACS,  the  operators  are  likely  to  send  their  traffic 
through  the  router  over  the  36  kbps  link.  This  seems  like  a 
reasonable  choice  given  the  larger  bandwidth  of  this  route 
and  the  delay  that  would  be  associated  with  data  ferrying. 
However,  S2’s  operators  are  likely  not  aware  that  there  will 
be  a  30-minute  period  where  S 1  is  also  sending  data  through 
the  router.  In  addition,  without  an  NTO,  the  router  itself  has 
no  way  of  knowing  the  relative  priorities  of  messages 
coming  from  SI  and  S2.  Even  if  the  router  is  using  a  proto¬ 
col  such  as  Differentiated  Services,17  SI  and  S2  have  not 
been  directed  what  forwarding  behaviors  to  put  in  their 
packet  headers. 

Next,  the  same  scenario  is  envisioned  with  an  NTO  pro¬ 
cess  in  place.  In  the  planning  phase,  analysts  expose  the 
potential  for  the  combined  data  rates  from  SI  and  S2  to 
overwhelm  the  router’s  queue.  The  time  span  from  1400  to 
1500  is  deemed  to  be  a  contention  period.  At  this  point, 
there  are  multiple  courses  of  action  available. 

1.  Increase  the  bandwidth  on  the  links  through  the 
router. 

2.  Deploy  a  second  router. 

3.  Turn  off  the  data  flow  from  S2  (neither  store  nor 
send)  during  the  contention  period. 

4.  Use  the  AWACS  as  a  data  ferry  during  the  conten¬ 
tion  period. 

5.  Give  the  router  a  priority  queue  and  mark  the  pack¬ 
ets  from  S 1  and  S2  with  relative  priorities. 

Options  1,  2,  and  5  are  rejected  because  they  require  a 
physical  change  to  or  addition  of  equipment.  Option  3  is 
rejected  because  even  though  the  data  is  of  lower  priority, 
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Figure  5.  Overhead  view  of  the  scenario 


the  loss  of  data  should  be  avoided.  Since  it  is  known  that 
the  information  from  S2  is  not  time-sensitive,  the  delay 
associated  with  option  4  is  tolerable.  This  course  of  action 
approval  is  made  at  the  operation  level  and  given  as  a  direc¬ 
tive  to  the  operators  of  S2  (and  also  of  the  AWACS)  through 
the  NTO.  The  increase  in  end-to-end  delay  for  S2  is  justi¬ 
fied  by  the  increased  reliability  of  the  overall  network  and 
the  lower  priority  of  S2’s  data. 

5.2.  Design 

The  scenario  is  implemented  in  the  open  source  ns-2  simu¬ 
lator  (version  2.29). ls  Traffic  is  generated  with  constant  bit 
rate  generators  using  UDP.  The  data  rates  at  which  SI  and 
S2  send  packets  can  be  achieved  in  many  ways  by  adjust¬ 
ing  packet  size  and  the  interval  between  packets.  One 
extreme  way  would  be  to  have  SI  send  a  3825-byte  packet 
once  per  second  and  for  S2  to  send  a  900-byte  packet  once 
per  second.  To  make  the  simulation  more  realistic,  packet 
sizes  of  8  bytes  through  64  bytes  in  steps  of  8  bytes  are 
considered  for  both  sources.  The  time  interval  between 
packets  is  adjusted  accordingly.  Random  jitter  is  added  to 
the  traffic  generators  to  prevent  having  consistent  simulta¬ 
neous  arrivals  at  the  router  of  packets  from  the  two  sources. 
Because  of  the  random  nature  of  the  traffic,  results  are 
gathered  using  30  different  random  seeds.  This  necessitates 
1920  simulation  runs  each  for  the  two  versions  of  the  sce¬ 
nario  (without  and  with  NTO).  The  various  connections 


are  implemented  as  simplex-links  with  5  ms  delays  and 
DropTail  queues  (with  default  buffer  size).  No  noise  or 
signal  fading  is  simulated. 

For  the  scenario  with  no  NTO  process  in  place  (S2  using 
the  router),  S2  generates  traffic  for  an  hour  with  S 1  generat¬ 
ing  traffic  for  the  30-minute  span  from  10-40  minutes.  For 
the  scenario  with  an  NTO  process  in  place  (S2  using  the 
AWACS),  the  timing  is  more  complicated.  S2  needs  to  send 
30-minutes  worth  of  data  within  a  10-minute  window  of 
opportunity.  To  allow  some  time  for  connections  to  be 
established  between  S2  and  the  AWACS,  it  is  arranged  for 
the  data  to  be  sent  in  only  8  minutes.  Consequently,  12.96 
Mb  (or  1.62  MB)  of  information  in  8  minutes  corresponds 
to  an  increased  rate  of  27  kbps.  The  worst  case  for  end-to- 
end  delay  happens  when  the  LOS  contact  between  HQ  and 
the  AWACS  ends  just  prior  to  when  the  LOS  contact 
between  S2  and  the  AWACS  begins.  This  is  the  situation 
modeled.  S 1  generates  traffic  for  the  30-minute  span  from 
10-40  minutes.  S2  sends  traffic  to  the  AWACS  in  two 
8-minute  intervals  from  0-8  minutes  and  from  30-38  min¬ 
utes.  The  AWACS  relays  the  traffic  to  HQ  in  two  8-minute 
intervals  from  22-30  minutes  and  from  52-60  minutes 

6.  Results 

The  results  from  the  scenario  without  an  NTO  process  in 
place  are  examined  first.  In  Figure  6,  the  mean  percentages 
of  packets  that  get  dropped  at  the  router  from  the  two 
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Figure  6.  Mean  percentage  of  packets  dropped  at  the  router  for 
the  router;  (b)  packets  originating  at  SI  dropped  at  the  router 


sources  are  shown,  broken  down  by  packet  size.  Cells  are 
shaded  based  on  their  value.  The  higher  the  percentage,  the 
darker  a  cell  is  shaded,  in  Figure  6(a),  it  can  be  seen  that  SI 
experiences  less  loss  when  packet  sizes  are  relatively  simi¬ 
lar.  S 1  suffers  the  least  loss  of  3 .45 1 8%  when  S 1  packets  are 
40  bytes  and  S2  packets  are  56  bytes.  The  largest  loss  of 
4.7082%  is  when  S 1  packets  are  32  bytes  and  S2  packets  are 
8  bytes.  Conversely,  S2  experiences  more  loss  when  packet 
sizes  are  relatively  similar,  as  seen  in  Figure  6(b).  S2  suffers 
the  least  loss  of  2.4988%  when  SI  packets  are  64  bytes  and 
S2  packets  are  16  bytes.  The  largest  loss  of  5.1471%  is 
when  SI  packets  are  16  bytes  and  S2  packets  are  24  bytes. 
The  confidence  intervals  on  these  means  are  pretty  tight. 
Figure  7  shows  the  95%  confidence  intervals  for  the  means 
when  fixing  the  size  of  one  source’s  packets.  Figure  7(a)  has 
Si’s  packets  fixed  at  56  bytes,  and  Figure  7(b)  has  S2’s 
packets  fixed  at  56  bytes.  These  graphs  are  typical  of  the 
confidence  intervals  for  all  mixtures  of  packet  sizes. 

It  is  important  to  note  that  for  no  combination  of  packet 
sizes  does  either  source  experience  an  acceptable  amount 
of  loss.  The  QoS  is  degraded  significantly  for  both  sources. 
The  high-priority  video  feed  losses  from  S 1  are  especially 
troubling.  The  suggested  tolerance  for  data  loss  is  below 
1%  for  high-quality  audio-video  streaming  and  2-3%  for 
two-way  interactive  audiovisual  services.19  These  toler¬ 
ances  are  all  surpassed  for  Si’s  data  stream. 

Since  UDP  does  not  retransmit  lost  packets,  it  may  be  of 
interest  to  see  what  the  total  loss  from  both  sources  is  in 


scenario  with  no  NTO:  (a)  packets  originating  at  SI  dropped  at 


terms  of  bytes.  The  table  in  Figure  8(a)  shows  the  mean 
percentage  of  total  bytes  lost  from  both  sources  at  the 
router,  broken  down  by  packet  sizes.  The  cells  are  again 
shaded  based  on  their  value,  but  the  range  of  values  is  rather 
narrow.  Percentages  range  from  3.9723%  to  4.0116%  with 
a  trend  of  higher  percentages  occurring  when  packet  sizes 
are  small  and  lower  percentages  occurring  when  packet 
sizes  are  larger.  Figure  8(b)  provides  a  summary  of  statis¬ 
tics  on  the  percentage  of  total  bytes  dropped  at  the  router 
over  all  1920  simulation  runs.  The  overall  average  is  a  loss 
of  3.9967%  of  the  total  bytes  sent,  with  a  very  narrow  95% 
confidence  interval  of  3.9947%  to  3.9986%. 

The  results  from  the  simulations  run  for  the  scenario 
with  an  NTO  are  very  simple.  No  packets  were  lost  from 
either  source,  regardless  of  the  mix  of  packet  sizes.  Also,  all 
data  sent  from  S2  to  the  AWACS  was  subsequently  sent 
from  the  AWACS  to  HQ.  Bear  in  mind  that  no  noise  or 
signal  fading  was  simulated;  however,  loss  from  those 
sources  would  mainly  apply  to  the  lower-priority  S2  data. 

7.  Conclusion 

The  main  conclusion  that  can  be  drawn  here  is  that  deci¬ 
sions  made  with  the  assistance  of  an  NTO  process  could 
have  a  positive  impact  on  the  overall  QoS  of  the  GIG.  The 
current  situation  is  one  of  local  scope.  With  no  other  infor¬ 
mation,  given  the  choice  between  a  higher  bandwidth  route 
with  small  delay  and  a  lower  bandwidth  route  with  large 
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Figure  7.  The  95%  confidence  intervals  for  the  mean  percentage  of  56-byte  packets  originating  at  (a)  SI  and  (b)  S2  dropped  at  the 
router  for  scenario  with  no  NTO 
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delay,  the  first  route  seems  to  be  the  better  option.  It  is  a 
greedy  choice  in  the  sense  that  it  appears  to  offer  the  best 
service  for  S2.  Having  an  NTO  process  in  place  allows  for 


a  more  global  view  of  the  situation.  It  would  allow  for  less- 
obvious,  but  in  the  long  run  better,  decisions  to  be  made. 
Here,  the  second  route  can  be  seen  as  the  better  choice  for 
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it  allows  the  high-priority  data  from  SI  to  flow  uninter¬ 
rupted,  and  all  of  the  data  from  S2  still  reaches  the  desti¬ 
nation  in  exchange  for  additional  delay.  Not  only  is  S2 
sacrificing  speed  for  the  benefit  of  SI,  but  S2  also  reaps  the 
benefit  of  not  losing  any  packets  itself. 

Modeling  and  simulation  has  been  used  to  quantify  the 
potential  benefit  of  implementing  an  NTO  process.  The 
scenario,  while  simple  and  intuitive,  is  realistic  and  shows 
how  the  NTO  can  really  make  a  difference.  Keep  in  mind 
that  the  intuitiveness  of  the  scenario  is  misleading.  The 
description  of  the  scenario  in  Section  5  is  basically  a  pre- 
NTO  in  narrative  format.  All  of  the  information  needed  to 
understand  the  scenario  is  conveniently  put  together  into 
one  place.  This  makes  it  clear  that  there  is  a  potential  con¬ 
flict,  but  in  current  practice,  no  such  convenience  exists. 
Something  as  complex  as  the  NTO  process  will  only  ever 
be  used  in  real  situations  if  it  can  be  demonstrated  that  its 
benefits  outweigh  the  cost  of  implementation. 
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